In der letzten Woche haben wir an vier Standorten meines Dienstherren Updates an unserem CRM und Eventplanungssystem durchgeführt.
Dieser Artikel beschreibt die Learnings, die ich für mich aus dem Ablauf rausziehe.
Ausgangssituation
Wir verwenden ein CRM sowie einen Eventmanager für die politische Kommunikation und die Planung von Veranstaltungen. Beide Produkte sind vor langer Zeit ausgewählt worden und haben ihre Vor- und Nachteile im täglichen Umgang.
Für sie spricht die Tatsache, dass Sie, abgesehen von einer WebExtension zum Hosten der Anmeldungsseiten für Veranstaltungen, keine direkte Verbindung "nach außen" benötigen, und somit im Vergleich zu manchem Online-System "relativ" sicher sind und wir die Anwendungs- und Datenbankserver im eigenen Netz hosten können.
Beide Produkte arbeiten gut zusammen, der Entwickler des Eventmanager hat diesen seinerzeit, so scheint es zumindest, speziell für die Zusammenarbeit mit diesen speziellen CRM-Tool entwickelt.
Wir brauchen Updates
Ich kam Ende November aus der Elternzeit zurück und wurde mit Rufen nach Updates begrüßt.
Dies war, wie sich im weiteren Verlauf notwendig, um für eine anstehende Großveranstaltung eine neue Landing-Page des EventManagers verwenden zu können.
Durch verschiedene Gründe verzögerte sich die Planung auf Ende Januar. Das Update sollte in einer Woche für alle vier Standorte durchgeführt werden.
Der Termin war dann auch der Letztmögliche, da Terminplanungen für das im Mai stattfindende Fest direkt im Anschluss starten mussten.
Wir hatten schlussendlich eine knappe Woche, um die Software paketieren zu lassen, den Rollout zu testen und die Nutzer über Blockzeiten zu informieren.
Learnings
Kommunikation ist alles
Die Verzögerung ergab sich teilweise aus der Kommunikation des Dienstleisters mit den Endnutzern. Die Existenz eines neuen Features (der Landing-Page) wurde einer der Fachabteilungen dargelegt, diese gab diese Information aber nicht oder nur unzureichend weiter. Mich erreichte Sie dadurch erst Ende Dezember.
Learning 1.1: Wenn solche Anfragen kommen möchte ich in Zukunft darauf achten, direkter mit den Endnutzern zu kommunizieren, statt auf die Aussagen der Boten zu vertrauen. Hier blieb einiges an Zeit und Infos liegen.
Jedoch wäre es zu einfach, die Schuld nur in diesem einen Patzer zu suchen. Auch verlief die Kommunikation mit dem Dienstleister nicht reibunsfrei.
Nach IT-Sicherheits-Vorgaben ist es notwendig, ein Changelog vorliegen zu haben, bevor wir die Software ausrollen können.
Dieses lag aber bis Anfang Januar noch nicht bereit.
Learning 1.2: Eine frühere Anforderung des Dokuments hätte hier Hektik und Verzögerung vermeiden können.
konkreter Ablaufplan für den Updatetag
Wir steuern die Zugriffe auf die einzelnen Standorte über AD-Gruppen. Je nachdem in welcher Gruppe man sich befindet, werden Systemparameter angepasst, die die Software auf eine andere Teildatenbank ausrichtet.
Ich hatte mir einen Dummynutzer erstellt, der als erster auf die migrierte Datenbank zugreifen sollte. In einem Vorgespräch wurde angedeutet, dass man mit dem geupdateten Client nicht auf einen nicht vorbereiteten Standort zugreifen sollte, da es zu Inkonsistenzen und Problemen kommen kann. Wir hatten zu diesem Zeitpunkt im Rahmen der Pakettests bereits drei Clients mit Updates ausgerollt. Diese waren markiert, damit sie nicht versehentlich im falschen Standort starteten.
Mein Dummy war auf die richtige Datenbank ausgerichtet, alles war bereit.
Während des ersten Tages kam es dann zu Schwierigkeiten bei der serverseitigen Installation. Ich wechselte per RDP auf eines der Testsysteme und meldete mich mit meinem normalen Nutzer an. Ich startete das CRM und wurde recht zügig mit einer Fehlermeldung begrüßt. Eine Abhängigkeit sei nicht definiert, die Datenbank könne nicht geöffnet werden. Hups
Mein Hauptnutzer zeigte auf einen anderen Standort. Aber es kam eine Fehlermeldung, kein Problem. Nutzer abmelden, Dummy anmelden. Zugriff funktioniert. Alles super.
Mittags war ich bereits im Feierabend, als sich ein Kollege meldete. "Standort X kommt nicht mehr auf die Datenbank"
Eine Stunde Telko mit dem Support unseres Dienstleisters später, mäßig abgelenkt durch meine Tochter auf meinem Schoß, fing ich an, den Ablauf für den nächsten Tag im Kopf zu skizieren.
- Registryeinträge händisch ändern
- alle meine Konten in der AD anpassen
- Variablen vor Termin händisch kontrollieren
Learning 2: Hätte ich diesen Plan bereits am ersten Tag gehabt, wäre mit Sicherheit irgendwas anderes schiefgegangen. Aber dafür sind Learnings ja da.
Testnutzer, lots of Testnutzer
Wir hatten einen Plan. Die Software ist auf allen Standorten gleich eingerichtet und konfiguriert. Funktioniert ein Standort, funktionieren alle Standorte.
Für Montag hatten wir zwei Testnutzer angesprochen, die ab ca. 10 Uhr bereit standen, um bei den Updates vorgezogen zu werden und das ganze Prozedere zu testen, bevor die Verteilung am Standort los ging.
Alles lief gut, Wesentliche Verzögerungen traten nicht auf.
Mittwoch wurde ein relativ kleiner Standort mit nur drei Nutzenden aktuallisiert. Die Vorbereitungen waren schnell abgeschlossen, der Rollout lief. Das Problem war, es kam keine Reaktion. DAs mag bei drei Nutzern nicht verwundern. Durch meine Teilzeitarbeit war ich aber nur bis 11 Uhr im Dienst, Für etwaige Fahler war also keine große Zeitspanne. Nach Montag Mittag war ich etwas angespannt, schließlich wollte ich nicht noch einen Nachmittag zwischen Nachmittagsbrei und Rechner verbringen.
Also fing ich an , den drei Nutzenden hinterherzutelefonieren. Ich erreichte eine Kollegin um 10:30 Uhr, drückte in aller Eile das Update durch, startete die Software, ... und es gab einen Fehler. Mittlerweile war 10:55 Uhr. Um 11 musste ich los, meine Tochter von der Kita abholen.
Mein Kollege übernahm dankenswerterweiße die weitere Betreuung des Problems. Ärgerlich war es aber denoch.
Zwei Standorte hatte ich noch vor mir, im Grunde war keine Zeit zum gegensteuern mehr. Ich musste jetzt zumindest für Donnerstag die Daumen drücken, dass es ohne Schwierigkeiten lief. Während das Update am dritten Standort lief, rief ich Nutzende aus Standort 4 an und bat sie, am nächsten Morgen als Testnutzer zur Verfügung zu stehen.
Learning 3: Verlass dich nicht auf einen Standort, sondern habüberall einen Ansprechpartner, um schnell reagieren zu können. Vor allem wenn du am Tag harte Zeitgrenzen hast.
Das Team mitnehmen
Eigentlich trivial, aber es wird von mir sehr schnell vergessen.
Ich habe mir Mails vorformuliert. Eine für früh Morgens, um den Standort über die Sperrung des Systems zu informieren.
Eine weitere für Mittags, sobald der Rollout der Softwarepakete startet.
Dem Team war auch grundsätzlich bewusst, dass wir die Updates durchführen.
Von den Mails wussten sie aber nichts. Die Rückfragen kamen dann recht schnell. Nutzer würden sich melden, die Software funktioniere nicht. Ob ich den keine Mail verschickt hätte. (-.-)
Learning 4: Um hier mehr Klarheit im Team zu schaffen, muss dieses in der Kommunikation mit dem Endnutzer mitgenommen werden. Ob CC da am Ende wirklich der richtige Weg ist, weiß ich nicht. Aber die Info muss auch an den First-Level-Support gelangen.
Was vom Tage übrig bleibt
Das Update ist deutlich besser gelaufen, als man in der kürze der Planung hätte erwarten können. Und nach Pareto-Prinzip ist es sogar perfekt gelaufen. Klar, dass immer etwas hakt oder im Getriebe knirscht.
Fehler zu machen ist ok, man sollte sie nur möglichst nicht wiederholen.
Das nächste Update kommt bestimmt und mit etwas Glück bewahre ich mir diese Learnings bis dahin im Hinterkopf.